[FIX] python: install a setuptools that can build Odoo's dependencies - #135

Description

Installing Odoo's requirements failed on gevent with BackendUnavailable: Cannot import 'setuptools.build_meta': odev pinned setuptools to 58–59 for python 3.8 to 3.11, and those versions
cannot serve as a PEP 517 backend for current pip, which is what --no-build-isolation builds
against. The floor is raised to 69.

It is also capped below 82, which removed pkg_resources. Odoo 15.0 and 16.0 import it
unconditionally in odoo/modules/module.py and odev runs both on python 3.10, where an uncapped
requirement resolves to setuptools 83 and odoo-bin stops importing altogether.

Neither bound had any effect before, because requirements were parsed with a regular expression
capturing a single operator and version and expecting the environment marker to follow the version
immediately. Any requirement combining two bounds lost the second one and its marker: the existing
setuptools>=58.0.0, <59.0.0; python_version >= '3.8' and python_version < '3.12' had always been
read as an unconditional setuptools>=58.0.0. Requirements are now parsed with
packaging.requirements.Requirement, which also removes the eval() of the comparison and of the
marker. Markers are evaluated against the python of the virtual environment being installed into,
not against the interpreter odev runs under, so a requirement conditioned on the python version
resolves for the Odoo installation it is meant for.

Missing system dependencies are now reported on any operating system

Odoo builds several of its dependencies from source, and those builds fail with errors that do not
name the system library they are missing — which is how #93 presents itself before it is diagnosed.
When creating a virtual environment, odev now says what is missing and, when it recognizes the
package manager, prints the command that installs it. It never installs anything itself.

Odev does not control the machine it runs on, so the check works everywhere:

• Where Odoo lists its own packages — Debian and Ubuntu, through setup/debinstall.sh --list, which
  only echoes what it parses out of debian/control and needs no privileges — that list is used
  as-is.
• Anywhere else the check falls back to probing what an executable on the PATH proves present, so
  that nothing is ever reported as missing on a distribution that merely names it differently.
• The development headers of python are checked on every system, because debian/control asks
  for python3-dev, which is not necessarily the version of python the Odoo installation is built
  against.

The new odev/common/system.py holds the whole platform vocabulary: package managers (apt-get,
dnf, zypper, pacman, apk, brew, distribution managers before Homebrew), and each
dependency with its per-manager package name and the executables proving it installed.

PythonEnv.install_system_packages used to raise Neither dnf or apt package managers found on the system anywhere else, naming neither the packages to install nor a way to move forward — reached
from create() whenever virtualenv cannot find the interpreter for an Odoo version, so odev run
dead-ended on Fedora, Arch and macOS. It now reports them and returns whether it installed anything,
so create gives up once instead of asking the same question again on a system where the answer
cannot change. It still runs the install on apt and dnf, unchanged: that path is pre-existing,
already sits behind two confirmations, and is how users get python3.10 installed. Naming a package
for pacman is safe, running sudo with a guessed name on a distribution odev has never been tested
against is not.

Risks worth knowing before merging

• The <82 cap downgrades setuptools for anyone who raised it by hand to work around this issue
  — which is exactly what the reporter did. That is the intended repair for Odoo 15.0 and 16.0, but
  it will surprise people.
• Honouring markers changes what gets installed from every requirements file odev reads, not
  just this one. Markers that were silently dropped are now applied, so packages that used to be
  installed on the wrong python version correctly stop being installed. It has its own commit.

Note for reviewers

The two commits are worth reading separately: the first is the setuptools and requirements-parser
fix, the second replaces the Debian-only dependency check it shipped with — including its
sudo debinstall.sh prompt, which is gone — with the cross-platform one described above. The
paragraph about that prompt in the first commit message is superseded by the second.

Tests: the setuptools specifier is asserted through packaging (at python 3.10 it must admit 69 and
81.2 and reject 58 — the #93 regression — and 82, the pkg_resources regression; at 3.7 it keeps
the legacy cap); missing_requirements is covered for two-bound specifiers and for markers
evaluated against the environment python. For the cross-platform half, the regression guard is a
darwin system with no compiler and no pg_config, which today reports nothing; plus a new
tests/tests/common/test_system.py, and assertions that no path ever shells out. Full test suite
passes.

Linked Issues

• closes Cannot import 'setuptools.build_meta' when installing gevent on Ubuntu 24.04 #93

Compliance

• I have read the contribution guide
• I made sure the documentation is up-to-date both in doctrings and the docs directory
• I have added or modified unit tests where necessary
• I have added new libraries to the requirements.txt file, if any
• I have incremented the version number according the versioning guide
• The PR contains my changes only and no other external commit

🤖 Generated with Claude Code

https://claude.ai/code/session_01K8csZBrrBYp8oqH5paxTAm